IBIS Macromodel Task Group

Meeting date: 11 February 2020

Members (asterisk for those attending):
Achronix Semiconductor:     * Hansel Dsilva
ANSYS:                        Dan Dvorscak
                              Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Kumar Keshavan
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
                              Todd Bermensolo
Marvell                       Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
SPISim:                     * Wei-hsing Huang
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Justin Butterfield took the minutes.

Hansel Dsilva from Achronix introduced himself.  He is working on high-speed 
SerDes development at Achronix.  He joined the meeting, since he has interest 
in improving SerDes modeling with IBIS-AMI.  Arpad asked Hansel if he is a 
model maker or model user.  Hansel replied he does both model development and 
uses the models.  Michael noted Hansel co-presented at the DesignCon IBIS 
Summit.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- None.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the February 5
meeting.  Michael moved to approve the minutes.  Walter seconded the motion.
There were no objections.


-------------
Discussion on “Gap in IBIS for sampling with statistical mode AMI models”:
Michael suggested to discuss Walter's comments and suggestions sent over 
email.  Walter summarized the potential issues starting on slide 14 of the 
DesignCon IBIS Summit presentation.  Walter noted, on slide 14, there are 6 
EDA tool results.  Four of the results seem to agree on the eye contour, while 
two results are outliers.  The cursor placement is not the same in any of the 
tools.  Slide 15 shows the same story, where the clock is not placed in the 
correct place.  Michael noted it is the sampling that is the issue.  Hansel 
agreed the clock sampling location is an issue in the statistical flow.  

Walter noted the standard flow only requires passing in the impulse response.  
The EDA tools may give different answers with the same model and the same 
channel.  There are several standard ways of aligning the clock.  Different 
specifications such as PCI and DDR5 define how to make these measurements at 
specific contours.  SiSoft uses rules that are specified as part of the 
channel transfer nets, and the simulation will have the standard's rules 
applied to the transfer nets.  He noted other EDA tools may do this 
differently.  The same model can be used for different standards, where the 
I/O will support different standards with different rules.  

Walter stated there is nothing in the AMI standard that prevents the model 
maker from reporting eye metrics.  Arpad commented, in time-domain simulation, 
the sampling position is generated by the CDR and relayed with clock ticks.  
He asked if we are lacking this capability for statistical.  Walter replied 
the model can return where it thinks the sampling should occur.  Arpad stated, 
in the time-domain, this done by the model, and he asked if the model should 
also do this for the statistical domain.  Walter noted there could be a 
reserved parameter for the model to output the sample point.  Michael 
commented there is an assumption that the EDA tool will build the pictures 
from the model raw data output.  GetWave has the clock_ticks information, and 
having information about where the DFE is making its decision would be very 
useful for statistical simulation.  This would require some knowledge of the 
sampling specification which would need to be supplied.  Michael would like to 
see a way for the model to specify the sampling point.  

Hansel noted the COM eye on slide 16 is much smaller than the EDA tool eyes, 
which shows how the sampling can effect the eye diagram.  Walter commented COM 
only calculates the data at the center of the eye, so it is not calculating 
the eye contour.  Hansel noted there has been an update in the COM tool which 
takes into account the position of the DFE cursors and can output the eye 
opening.  Walter noted this is the COM tool, but this is not in the COM 
standard.  Walter noted there is an IEEE standard for COM, but the COM tool 
goes beyond the specification.  There is no reason the COM tool would be any 
better than any of the other EDA tools.  The COM tool and the COM signal to 
noise analysis calculation methods are independent.

Arpad asked how can we improve on this situation and whose responsibility is 
it to output the sampling.  Walter noted the model could return where the 
sampling location is, but this is not trivial.  The other option is to have a 
standard to reflect how the tools should analyze the model results to 
determine the sampling point.  Another possibility is to have a reserved 
parameter to specify where to place the clock.  Walter noted he likes the idea 
of having the model tell the EDA tool where to place the clock in the 
statistical flow.  Arpad suggested for everyone to think about these options, 
and he would call for a straw man poll in a future meeting.  Michael and 
Walter agreed this would be a good approach.


DDR Clock Forwarding:
Fangyi noted last week there were some questions, so he has added slides to 
address the questions.  He added a slide to address the simulation flow and 
the necessary steps.  He included crosstalk for DQ and DQS.  The first step is 
to compute the analog channel response.  The second step is to compute the DQS 
Rx DLL output.  The third step is to use the GetWave2 function for the DQ Rx 
DLL with the output DQS Rx DLL.  

Walter commented the skew at the latch inside the DRAM is critical.  If you 
have the DQ with the two inputs for DQ and DQS, the model can have two 
independent internal paths.  He would much prefer to have one DLL for both DQ 
and DQS.  Fangyi noted he has updated the proposal to include the delay 
between DQ and DQS.  Walter asked how the delay is known in the Rx DLL.  
Fangyi replied it is up to the model developer.  The model maker could bypass 
the DQS DLL and go directly to the DQ DLL.  Walter stated it would be much 
simpler for the EDA tool to have one DLL.  Fangyi commented you still need the 
DQS DLL for anything the model maker wants to model in the DQS path.  Walter 
noted the tool can pass in the waveforms from the DQ and DQS into the DLL.  
Fangyi does not want to exclude the model maker from having the DQS model have 
its own functionality.

Ambrish asked if the AMI model can process the analog waveform from the DQS.  
Fangyi stated the DQS can be a pass through.  Ambrish asked if clock_ticks can 
be used as an input to the DQ DLL.  Fangyi replied that the clock_ticks do not 
relay the slew rate information.  Walter noted clock_ticks could be made to 
have enough samples to include the whole waveform.  We could either create a 
new function or use clock ticks to input the waveform.  Fangyi proposed to add 
a new function, so as to not confuse what we already have in the standard.  
Walter agreed this is a detail we can work out.  

Walter commented there is no reason that the GetWave blocks for DQ and DQS to 
not be the in the same function.  There could be some delay due to the 
processing, and the samples coming in could be different from the samples 
coming out.  Walter noted it is critical to model the DQS delay to the slicer, 
it is important to get this correct in the simulation architecture.  Adding 
the DQS DLL in the path could be problematic.  Arpad asked, since the model 
maker is making both DQ and DQS models, this can be made to work.  Walter 
noted the DQS DLL would only have a CTLE.  He asked Michael and Randy for 
their thoughts.  Randy replied he would have to think about it.  Michael 
replied he would have to discuss the issue internally.


BIRD201:
Walter suggested a library of protocols as an ongoing discussion topic.


New BIRDs from Editorial Task Group?
Arpad asked if this can be removed from the agenda.  Bob suggested to keep 
it.  Walter asked if Bob wanted to take ownership of this.  Bob stated this is 
a a possibility, but progress would be slow.


Jitter HF/LF components and Jitter Amplification:
Arpad asked Michael about this topic.  Michael would like to keep this topic 
on the list for future discussion.


Tabled ARs:
Arpad asked if we should keep the tabled ARs for Michael and Randy.  Michael 
stated we are already in these discussions on the clocking and protocols.  
Randy agreed.  Michael suggested these can be deleted.


- Michael M.: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

-------------
Next meeting: 18 February 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
